home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 4 / QRZ Ham Radio Callsign Database - Volume 4.iso / digests / tcp / 940168.txt < prev    next >
Internet Message Format  |  1994-11-13  |  13KB

  1. Date: Tue,  9 Aug 94 04:30:02 PDT
  2. From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
  3. Errors-To: TCP-Group-Errors@UCSD.Edu
  4. Reply-To: TCP-Group@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: TCP-Group Digest V94 #168
  7. To: tcp-group-digest
  8.  
  9.  
  10. TCP-Group Digest            Tue,  9 Aug 94       Volume 94 : Issue  168
  11.  
  12. Today's Topics:
  13.                             DNS  (4 msgs)
  14.                  NET/ROM, TexNet and Rose Information
  15.                            SMTP LZW oddity
  16.                   TCP-Group Digest V94 #167 (2 msgs)
  17.  
  18. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
  19. Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
  20. Problems you can't solve otherwise to brian@ucsd.edu.
  21.  
  22. Archives of past issues of the TCP-Group Digest are available
  23. (by FTP only) from UCSD.Edu in directory "mailarchives".
  24.  
  25. We trust that readers are intelligent enough to realize that all text
  26. herein consists of personal comments and does not represent the official
  27. policies or positions of any party.  Your mileage may vary.  So there.
  28. ----------------------------------------------------------------------
  29.  
  30. Date: Mon, 08 Aug 94 16:23:00 -0000
  31. From: mikebw@bilow.bilow.uu.ids.net (Mike Bilow)
  32. Subject: DNS
  33. To: TCP-Group@UCSD.EDU
  34.  
  35.  RF> I need to configure ka9q as a DNS.  The version that I have does not
  36.  RF> appear to support DNS.  Therefore which copy of ka9q or other variety of
  37.  RF> nos do I require to produce a DNS
  38.  
  39. My advice is: don't do it.  If you need a good, reliable name server, use
  40. Linux.  None of the NOS DNS code I have seen correctly implements the most
  41. basic elements of the standards, such as TTL and authoritativeness, and is
  42. really only useful in slave mode.  The Linux named seems to be very solid, and
  43. has all of the same bells and whistles as BSD Unix.
  44.  
  45. If you need to put it on the radio, then you could try the kernel patches for
  46. AX.25 or even link the Linux box to a KA9Q machine with Ethernet.
  47.  
  48. -- Mike
  49.  
  50. P.S. We found a bug in the 1.1.39 Linux beta kernel that affects DNS.  If you
  51. are a primary authoritative server from which secondary authoritative servers
  52. attempt to do zone refresh, the zone refresh fails.  We don't know why, but the
  53. current release kernel, 1.0.9, works fine.
  54.  
  55. ------------------------------
  56.  
  57. Date: Mon, 08 Aug 1994 17:33:09 -0400
  58. From: "Brandon S. Allbery" <bsa@kf8nh.wariat.org>
  59. Subject: DNS 
  60. To: mikebw@bilow.bilow.uu.ids.net
  61.  
  62. In your message of Mon, 08 Aug 1994 16:23:00 -0000, you write:
  63. +---------------
  64. | My advice is: don't do it.  If you need a good, reliable name server, use
  65. | Linux.  None of the NOS DNS code I have seen correctly implements the most
  66. | basic elements of the standards, such as TTL and authoritativeness, and is
  67. | really only useful in slave mode.  The Linux named seems to be very solid, 
  68. and
  69. | has all of the same bells and whistles as BSD Unix.
  70. +------------->8
  71.  
  72. That's because it *is* the BSD named... Linux kernel networking code isn't 
  73. based on BSD kernel networking code, but most of the non-kernel network code 
  74. is straight BSD.
  75.  
  76. | If you need to put it on the radio, then you could try the kernel patches for
  77. | AX.25 or even link the Linux box to a KA9Q machine with Ethernet.
  78. +------------->8
  79.  
  80. Or JNOS/Linux via SLIP over a pty (works fine here!).
  81.  
  82. ++Brandon
  83. -- 
  84. Brandon S. Allbery KF8NH     [44.70.4.88]          bsa@kf8nh.wariat.org
  85. Linux development:  iBCS2, JNOS, MH
  86.  
  87. ------------------------------
  88.  
  89. Date: Mon, 08 Aug 1994 17:33:09 -0400
  90. From: "Brandon S. Allbery" <bsa@kf8nh.wariat.org>
  91. Subject: DNS 
  92. To: mikebw@bilow.bilow.uu.ids.net
  93.  
  94. In your message of Mon, 08 Aug 1994 16:23:00 -0000, you write:
  95. +---------------
  96. | My advice is: don't do it.  If you need a good, reliable name server, use
  97. | Linux.  None of the NOS DNS code I have seen correctly implements the most
  98. | basic elements of the standards, such as TTL and authoritativeness, and is
  99. | really only useful in slave mode.  The Linux named seems to be very solid, 
  100. and
  101. | has all of the same bells and whistles as BSD Unix.
  102. +------------->8
  103.  
  104. That's because it *is* the BSD named... Linux kernel networking code isn't 
  105. based on BSD kernel networking code, but most of the non-kernel network code 
  106. is straight BSD.
  107.  
  108. | If you need to put it on the radio, then you could try the kernel patches for
  109. | AX.25 or even link the Linux box to a KA9Q machine with Ethernet.
  110. +------------->8
  111.  
  112. Or JNOS/Linux via SLIP over a pty (works fine here!).
  113.  
  114. ++Brandon
  115. -- 
  116. Brandon S. Allbery KF8NH     [44.70.4.88]          bsa@kf8nh.wariat.org
  117. Linux development:  iBCS2, JNOS, MH
  118.  
  119. ------------------------------
  120.  
  121. Date: Mon, 8 Aug 1994 23:24:12 -0500 (CDT)
  122. From: ssampson@sabea-oc.af.mil (Steve Sampson)
  123. Subject: DNS
  124. To: tcp-group@ucsd.edu
  125.  
  126. > Which version of NOS has DNS?
  127.  
  128. The versions in ftp.ucsd.edu:/hamradio/packet/tcpip
  129.  
  130.     /ka9q        (NOS)
  131.     /pa0gri        (GRINOS)
  132.     /wg7j        (JNOS)
  133.  
  134. My favorite is NetBSD, GRINOS, JNOS, NOS, in that order :-)
  135. But I just got my copy of Yggdrasil Linux, so we'll
  136. see how it's DNS (named) fairs...
  137.  
  138. -- 
  139. Steve, N5OWK
  140.  
  141. ------------------------------
  142.  
  143. Date: Mon, 8 Aug 94 11:42 CST
  144. From: emillar@enlaces.ufro.cl (Eduardo Millar)
  145. Subject: NET/ROM, TexNet and Rose Information
  146. To: ham-digital@ucsd.edu
  147.  
  148. Hello: Does anyone could give me  information about NET/ROM, TexNet and Rose? 
  149.  
  150.  _____________________________________________________________________
  151.  
  152.    Eduardo Millar C.             e-mail: emillar@enlaces.ufro.cl
  153.    Proyecto Enlaces              fono/fax: 250759
  154.    Universidad de la frontera    Casilla 380 Temuco - Chile
  155.  _____________________________________________________________________
  156.  
  157. ------------------------------
  158.  
  159. Date: Mon, 08 Aug 94 16:33:00 -0000
  160. From: mikebw@bilow.bilow.uu.ids.net (Mike Bilow)
  161. Subject: SMTP LZW oddity
  162. To: TCP-Group@UCSD.EDU
  163.  
  164.  A> In all the code I've seen (apart from my own modified versions),
  165.  A> the SMTP LZW exchange goes like this:
  166.  
  167.  A> Client sends   "XLZW <x> <y>"
  168.  
  169.  A> Server checks that it can do LZW with these parameters, if so it
  170.  A> replies with   "25n XLZW <m> <n> OK" and goes to compressed mode.
  171.  
  172.  A> The client checks the response, and iff (m = x) and (n = y) then
  173.  A> it too goes to compressed mode.
  174.  
  175. It is not true that (m = x) and (n = y) are the requirements.  In fact, the
  176. requirement is only that (m <= x) and (n <= y), as I recall.
  177.  
  178.  A> My question is: why does the client check <m> and <n> ? It's too
  179.  A> late for the client to decide to not go to compressed mode - the
  180.  A> server has already gone compressed.
  181.  
  182. The client offers to do compression and says, "I have enough memory and
  183. processing resources to use a maximum of (x, y) compression.  How are you
  184. feeling today?"  The server may then answer, "I have only enough resources to
  185. do (m, n) compression, where (m < x) or (n < y)."
  186.  
  187.  A> The server code looks as though, in theory, it could return different
  188.  A> values from those the client supplied.
  189.  
  190. As long as the protocol requires that the server return a maximum of the offer
  191. made by client, there is no problem.  After all, the server cannot use higher
  192. compression than the client is capable of supporting.
  193.  
  194.  A> There may not necessarily be a problem in practice, but from a
  195.  A> protocol point of view the exchange seems wrong.
  196.  
  197. It probably could have been done better.
  198.  
  199. -- Mike
  200.  
  201. ------------------------------
  202.  
  203. Date: Tue, 9 Aug 1994 09:51:28 CET
  204. From: "Jack Stiekema" <JACK@vic1.victron.nl>
  205. Subject: TCP-Group Digest V94 #167
  206. To: freemanr@dstos3.dsto.gov.au, tcp-group@ucsd.edu
  207.  
  208. >>Date: Sun, 7 Aug 1994 23:42:15 -0700
  209. >>From: freemanr@dstos3.dsto.gov.au (Roy Freeman)
  210. >>To: TCP-Group@UCSD.EDU
  211. >>
  212. >>I need to configure ka9q as a DNS.  The version that I have does not appear
  213. >>to support DNS.  Therefore which copy of ka9q or other variety of
  214. >>nos do I require to produce a DNS
  215.  
  216. The originals are at ftp.ucsd.edu somewhere in
  217. pub/ham/packet/tcpip/ka9q.
  218. There is also a working exe with DNS.
  219.  
  220. Cheers,
  221.  
  222.  
  223. Kind regards,
  224. Jack Stiekema
  225. Product Manager Connectivity
  226. +------------------------------------------------+
  227. |  Phone: +31 50 446284   or   +31 6 53145069    |
  228. |  Fax:   +31 50 424107  Email jack@victron.nl   |
  229. | Victron bv  POB 31  9700 AA Groningen  Holland |
  230. +------------------------------------------------+
  231.  
  232. ------------------------------
  233.  
  234. Date: Tue, 09 Aug 94 12:57:25 GMT-1
  235. From: Postmaster@86wg.ram.af.mil
  236. Subject: TCP-Group Digest V94 #167
  237. To: tcp-group@UCSD.EDU
  238.  
  239. Returned Mail: User cgscmpa@86wg.ram.af.mil Unknown
  240.  
  241. *** Returned Mail Message Follows: ***
  242. >From @ramstein.af.mil:owner-tcp-digest@UCSD.EDU Tue 09 Aug 1994 12:55
  243. X-Envelope-To: cgscmpa@86wg.ra
  244.     id AA11829; Mon, 8 Aug 94 18:16:22 GMT
  245. Received: by ucsd.edu; id EAA02739
  246.     sendmail 8.6.9/UCSD-2.2-sun
  247.     Mon, 8 Aug 1994 04:30:06 -0700 for tcp-digest-list
  248. Received: by ucsd.edu; id EAA02730
  249.     sendmail 8.6.9/UCSD-2.2-sun
  250.     Mon, 8 Aug 1994 04:30:05 -0700 for tcp-group-ddist
  251. Message-Id: <199408081130.EAA02730@ucsd.edu>
  252. Date: Mon,  8 Aug 94 04:30:03 PDT
  253. From: Advanced Amateur Radio Networking Group <tcp-group@UCSD.EDU>
  254. Errors-To: TCP-Group-Errors@UCSD.EDU
  255. Reply-To: TCP-Group@UCSD.EDU
  256. Precedence: Bulk
  257. Subject: TCP-Group Digest V94 #167
  258. To: tcp-group-digest@UCSD.EDU
  259.  
  260.  
  261.  
  262. TCP-Group Digest            Mon,  8 Aug 94       Volume 94 : Issue  167
  263.  
  264. Today's Topics:
  265.                            SMTP LZW oddity
  266.  
  267. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
  268. Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
  269. Problems you can't solve otherwise to brian@ucsd.edu.
  270.  
  271. Archives of past issues of the TCP-Group Digest are available
  272. (by FTP only) from UCSD.Edu in directory "mailarchives".
  273.  
  274. We trust that readers are intelligent enough to realize that all text
  275. herein consists of personal comments and does not represent the official
  276. policies or positions of any party.  Your mileage may vary.  So there.
  277. ----------------------------------------------------------------------
  278.  
  279. Date: Mon, 8 Aug 94 09:46:48 +0100
  280. From: A.D.S.Benham@bnr.co.uk
  281. Subject: SMTP LZW oddity
  282. To: TCP-Group@UCSD.Edu, nos-bbs@hydra.carleton.ca
  283.  
  284. In all the code I've seen (apart from my own modified versions),
  285. the SMTP LZW exchange goes like this:
  286.  
  287. Client sends   "XLZW <x> <y>"
  288.  
  289. Server checks that it can do LZW with these parameters, if so it
  290. replies with   "25n XLZW <m> <n> OK" and goes to compressed mode.
  291.  
  292. The client checks the response, and iff (m = x) and (n = y) then
  293. it too goes to compressed mode.
  294.  
  295.  
  296. My question is: why does the client check <m> and <n> ? It's too
  297. late for the client to decide to not go to compressed mode - the
  298. server has already gone compressed.
  299.  
  300. The server code looks as though, in theory, it could return different
  301. values from those the client supplied.
  302. There may not necessarily be a problem in practice, but from a
  303. protocol point of view the exchange seems wrong.
  304.  
  305.  
  306. Andrew Benham
  307. --------------------------------------------------------------------
  308. adsb@bnr.co.uk   BNR Europe Ltd, 140 Greenway, Harlow Business Park,
  309.                                  Harlow, Essex CM19 5QD
  310.                  +44 279 402372    Fax: +44 279 402029
  311. Home:            g8fsl@g8fsl.ampr.org [44.131.181.17]
  312. --------------------------------------------------------------------
  313.  
  314. ------------------------------
  315.  
  316. Date: Sun, 7 Aug 1994 23:42:15 -0700
  317. From: freemanr@dstos3.dsto.gov.au (Roy Freeman)
  318. To: TCP-Group@UCSD.EDU
  319.  
  320. I need to configure ka9q as a DNS.  The version that I have does not appear 
  321. to support DNS.  Therefore which copy of ka9q or other variety of
  322. nos do I require to produce a DNS
  323.  
  324. ------------------------------
  325.  
  326. End of TCP-Group Digest V94 #167
  327. ******************************
  328.  
  329. ------------------------------
  330.  
  331. Date: Mon, 08 Aug 1994 20:39:11 -0400
  332. From: "Scot M. Gardner" <smg@math.ufl.edu>
  333. To: tcp-group@UCSD.EDU
  334.  
  335. +- On Monday (8/8/1994 18:11) "Scot M. Gardner" <smg@math.ufl.edu> Wrote-
  336.  
  337. Ack! My appologies. That was supposed to be to tcp-group-request,
  338. NOT to tcp-group.
  339.  
  340. A previous sysadmin subscribed root and now I'm trying
  341. to get off! Of course, I don't know what they subscribed
  342. under.
  343.  
  344. Can list admin remove me, please??!
  345.  
  346. Once again, my apologies.
  347.  
  348. | list root@math.ufl.edu
  349. | list root@matrix.math.ufl.edu
  350. | list root@mathlab.math.ufl.edu
  351. | list netadm@matrix.math.ufl.edu
  352. | list system@matrix.math.ufl.edu
  353. | list system@mathlab.math.ufl.edu
  354.  
  355. Scot Gardner
  356.             University of Florida Department of Mathematics
  357.          Computer Programmer/Analyst (904) 392-8501, Walker 3
  358.              Scot M. Gardner    email: smg@math.ufl.edu
  359.          web:<a href="http://www.math.ufl.edu/~smg">click</a>
  360.  
  361. ------------------------------
  362.  
  363. Date: Mon, 8 Aug 1994 18:11:11 -0400
  364. From: "Scot M. Gardner" <smg@math.ufl.edu>
  365. To: tcp-group@ucsd.edu
  366.  
  367. list root@math.ufl.edu
  368. list root@matrix.math.ufl.edu
  369. list root@mathlab.math.ufl.edu
  370. list netadm@matrix.math.ufl.edu
  371. list system@matrix.math.ufl.edu
  372. list system@mathlab.math.ufl.edu
  373.  
  374. ------------------------------
  375.  
  376. End of TCP-Group Digest V94 #168
  377. ******************************
  378.